The invention relates in general to the field of computer software optimization and, more particularly, to run-time alterations in operating system resource allocation data. Specifically, the invention describes a method for dynamically altering operating system kernel resource control tables without the need to shut-down and reboot the computer system to invoke the changes.
An application executing under the control of, for example, the Unix operating system requests the use or allocation of resources controlled by the kernel through a mechanism known as a system call. The system call technique provides a standard interface in all currently available Unix variants and is essentially a branch table indexed by the function being requested. See FIG. 1. A non-exhaustive set of system call examples include open a file, close a file, allocate memory, perform an input-output (I/O) operation, and allocate or use an interprocess communication resource such as a message queue, semaphore, or shared memory.
As part of the processing of a system call, special kernel program code switches the state of the operating environment from that of the application (commonly referred to as user mode, problem state, or protected mode) to a state required by the kernel to accomplish its control tasks (commonly referred to as kernel mode, supervisor state, or privileged mode). It then indexes into the branch table (commonly called a system table 100), extracts the address 105 of the routine to process the requested function, and calls the routine 120 at that address to perform the requested function. When the kernel function 120 has completed its processing, it returns its result(s) and control back to the operating environment (e.g., user or protected mode) of the application that originated the system call.
1.1 Resource Allocation
In a specific example a system call is executed to allocate, control, update or manipulate, and release resources associated with semaphores, shared memory and message queues which are collectively known as interprocess communications (IPC) facilities. In the allocate functions, such as Unix's semget, shmget, and msgget, the application making the IPC resource request submits a key with which to uniquely identify the resource and any information required to define or initialize the resource (e.g. size of shared memory segment, number of semaphores, and access permissions). In response to the request, the kernel generates and returns an identifier, referred to as a kernel identifier, which is used by the calling application in all further references to the resource or resource set; those resources allocated during the allocate process. (A kernel identifier is, generally, a numeric value returned to an application program, from the kernel, that identifies a specific resource element. For example, if an application program requests a shared memory segment from the kernel, the returned kernel identifier identifies the specific resource control blocks for that shared memory segment.) In all subsequent actions or control functions executed against the allocated resource, the kernel identifier is submitted as a parameter in the system call to identify the target resource set to the kernel.
As part of the allocation process, the kernel makes several determinations on the "get resource" request. If no resource is currently in existence for the submitted kernel identifier, the kernel attempts to allocate the requested resource by determining if there is a sufficient quantity of the resource available to satisfy the request and a free control structure (commonly known as semid.sub.-- ds, shmid.sub.-- ds, or msqid.sub.-- ds) in the kernel to represent the resource set. For each resource, there is a preset system-wide limit of the number of these control structures (and therefore kernel identifiers) that can be active at any one time. If a control structure is available, then it is initialized using the information provided in the system call parameter list and a kernel identifier is generated based on which control structure was found available.
If, on the other hand, the application executes a system call using a kernel identifier that is already associated with a resource (e.g., resource control structure), the kernel perform is a validation process to ensure the calling application is authorized to use the identified resource. If it is, the kernel identifier already assigned to the referenced resource is returned to the application. In this way, many applications can share a resource.
1.2 Allocation of Kernel Control Structures
Kernel control structures are generally organized into arrays or tables herein referred to as resource control tables. Because the number/quantity of any specified resource is known at system startup time, resource control tables may be created as static or dynamic memory elements. That is, a resource control tables memory allocation is defined in such a way as to make its location and size constant.
Static allocation is realized in the way a particular structure (e.g., resource control table) is defined in the kernel's program. For example, in the C programming language, a static array/table can be created by defining an instance of a structure array in the global data space by using the following statement:
struct sample { int a; int b;} sampletable 100!; PA1 struct sample *sampletable; PA1 sampletable=(sample *) malloc(100 * size of(sample))
This statement creates a static array identified by the name `sampletable` having 100 elements, where each element is of type `sample.` As would be well known to those of ordinary skill, this type of array can be defined using other programming languages using definition statements that are equivalent in function to those stated here for the C programming language.
Key aspects of the sampletable structure (see FIG. 2) created using static allocation techniques include: (1) it is created in the compile or assembly phase of program development; (2) table initialization, if any, is done during the compile or assembly phase as well; (3) the table's location in memory is determined by references to the array name sampletable 200; (4) the table's memory space is part of the executable object 205 and cannot be released or reused; and (5) the compiler, or assembler, will have placed other data elements of global scope around this structure array, 210 and 215, rendering it impossible to increase the number of elements in the array while leaving it at the same location in the executable program.
Dynamic allocation, in contrast, is performed at run-time, i.e., during program execution. In this method, definition of the `sampletable` data structure takes the form of a pointer in the program, where only the pointer is defined at compile or assemble time. Only at program execution, such as during program startup or when the array is first referenced, would the sampletable structure be initialized. Typically, initialization can take the form of a call to a free storage management routine (such as malloc or calloc) provided by the operating environment to acquire the address of a section of memory large enough to hold an array of the desired number of elements. The address of the memory section would be placed into the pointer variable, referenced by the name sampletable. References to the array would thereafter be accomplished by using the address contained in the pointer variable (array name). Again using the C programming language as an example, this could be accomplished with the following code fragment:
Key aspects of the sampletable structure (see FIG. 3) created using dynamic allocation techniques include: (1) the only storage reserved during the compile or assembly phase is for the pointer to the array sampletable 300; (2) storage for the array sampletable is not part of the executable module 305 loaded at run-time; (3) storage for the sampletable array must be acquired and initialized during execution of the program if sampletable is to be used during program execution; (4) location of the dynamic array in memory 310 is determined only by the contents of the pointer variable (sampletable 300); and (5) the location and size of the array 310 can be altered by controlling access to the pointer variable while its contents are updated to reference a different memory location containing an array with a different number of elements.
Kernel control structures are normally stored in contiguous tables or arrays with the table initialized to contain the number of structures defined by a system-wide limit value; kernel control structures may be statically defined data structures. While the method of generating resource identifiers varies slightly between various kernel implementations, in substantially all cases the position of the selected structure in the array (its index) and a sequence number maintained in each control structure are inputs to the function that generates the kernel identifier. This implies that changing the system-wide limit of kernel identifiers for any given resource affects the use of all the kernel identifiers currently in use by application programs in the system.
1.3 Drawbacks to Prior Art Resource Management
There are a number of undesirable constraints placed on users or applications due to the conventional implementation described above. The first being that any tuning desired to make a Unix kernel operate more efficiently under a given workload (set of applications or users executing at the same time), requires a system outage be endured by all users. Consequently all applications executing prior to the change in system resource capabilities will require restarting.
It would be beneficial to be able to alter kernel tuning parameters without an outage of services in order to improve the efficiency or even to determine what settings provide the optimum efficiency. Further it would be beneficial to be able to alter the quantity of certain resources available to users/applications (e.g. IPC facilities) dynamically; either to increase the quantity of a resource to allow more users/applications to utilize the benefits of that resource or to decrease availability to conserve or control access to resources in a constrained environment.